AMOS PD CD/amospdcd.iso/aminet/amoslist0993.lzh/AMOSLIST2/[e-mail]_Thu Sep 2 22:29:16 1993.msg

Internet Message Format | 1993-09-03 | 9KB

Received: from nextsun.INS.CWRU.Edu by access.digex.net with SMTP id AA03343
  (5.65c/IDA-1.4.4 for <[e-mail]>); Thu, 2 Sep 1993 22:29:13 -0400
Received: from svcs1.digex.net by nextsun.INS.CWRU.Edu with SMTP (5.65b+ida+/CWRU-1.5.2-freenet-gw)
    id AA25093; Thu, 2 Sep 93 22:28:48 -0400 (from [e-mail] for [e-mail])
Received: by svcs1.digex.net id AA27849
  (5.65c/IDA-1.4.4 for amos-list-out); Thu, 2 Sep 1993 22:15:58 -0400
Received: from access.digex.net by svcs1.digex.net with SMTP id AA27845
  (5.65c/IDA-1.4.4 for <[e-mail]>); Thu, 2 Sep 1993 22:15:56 -0400
Received: from vax.mbhs.edu by access.digex.net with SMTP id AA02109
  (5.65c/IDA-1.4.4 for <[e-mail]>); Thu, 2 Sep 1993 22:15:45 -0400
Message-Id: <[e-mail]>
Date: 2 Sep 93 22:05:00 EST
From: "Andrew Church" <[e-mail]>
Subject: Screen Flickering
To: "amos-list" <[e-mail]>
Status: O

  This is another multi-reply message.  (Don't worry, no dinosaurs.)

>>  Or have XOFS and YOFS variables, and a _WAIT_VBL procedure that does the
>>Screen Offset right after the Wait Vbl.  This is similar to what I do in a C
>>program I have that needs to scroll a screen around, except I use the Vbl
>>interrupt.  I still get a bit of flicker, but little enough that I don't
>>worry abot it.
>
>What is an XOFS or a YOFS?

  X OFfSet and Y OFfSet - internal screen location variables, equivalent to
the parameters to Screen Offset.

>Theoretically, to move a screen around, I should be able to double buffer - and
>update the nondisplayed screen at my convenience. At or during VBL I should be
>able to swap screens (presumably just change a pointer somewhere) VERY QUICKLY.
>
>I would be supprised to get ANY flicker - perhaps it would indicate that I am
>trying to do too much or too many things after the start of VBL.
>
>Do you NEED to Screen Offset just after Wait Vbl only because you are not
>double buffering?

  That's right... I don't double-buffer, because I found that the extra
updating took too long.

>>  It doesn't really matter whether you do Wait Vbl or Screen Swap first, as
>>long as you have them both (or you have some other way to make sure you only
>>do one Screen Swap per Vbl).
>
>Ok! This is useful information!

  No, it's not.  Everybody else was right -- it has to be before the vertical
blank.  Stupid me.

>So screen swap really means, "Swap Screen AT next VBL". (Or is that DURING,
>or AFTER?)

  "Swap Screen AT next VBL".

>You might like to fill me in on the low level mechanism of the graphics/copper
>stuff.

  Well, seeing as someone else already has, I won't bother.

>And anyhow: How do you know these things? Have you looked at the AMOS source?
>Is this just conjecture as to how it should be done? How you would do it? The
>only way possible?
><fx: no offence! Just checking your credentials!>

  Well, I don't know for sure, but it is the most sensible way to do it.
They could also have a separate task that gets a signal after a Screen
Swap, modifies the copper list, and returns to AMOS, but that's the long
way (or at least, *a* long way).

>As far as I know, the correct order is
>
>     Do
>    ... your drawing ...
>    Screen Swap
>    Wait Vbl
>     Loop

  That it is.

>I've always used this for flicker-free drawing, and the majority of other
>programs I have seen do as well.  The Screen Swap command simply exchanges
>the copper list pointers for the physical and logical screens.  The copper
>is already executing the list for the current physical screen, so you don't
>actually interrupt the display at the exact instant you call Screen Swap:
>the change only happens at the start of the next frame.  However, drawing
>commands are immediately affected - they are directed to the current logical
>screen.  So if you do a screen swap, then draw immediately, your display
>will flicker like a bastard, since your logical screen is halfway through
>being displayed!  If you follow your Screen Swap with a Wait Vbl, you wait
>until the current display is finished.  Then the copper pointer is updated
>from your new physical screen and your logical screen flips to the back, and
>you can start drawing over again.

  Good point, forgot about that.  You could use the Physic() function to
return the "physical" screen number (which is still not displayed until the
vertical blank).

>> In fact, it sounds CRUCIAL to have the Screen Swap BEFORE the Wait Vbl.
>
>It is.  I can't see how having them the other way round can get useful
>results, though I expect it could be good for something.  Winning the
>"flicker of the century award" perhaps? :)

  Naah... try a loop in which your program draws stuff, then does Screen
Offset inthe middle of the display.  My RPG (in C) did that... it was rather
interesting to be seeing two separate parts of the display at once.  :-)

>Screen swap is just a change of pointers... I haven't looked in screen base
>but assume they're there..

  Yup.  The first 6 longwords are the current (logical) bitplane pointers,
or just THE bitplane pointers for a single-buffered screen.  If the screen
is double-buffered, the next 6 longwords are the pointers to one screen, and
the 6 after that are the pointers to the other screen.  (If AMOS starts to
support AGA, all this will change, of course...)

>>   If you have a Shell window open, Close Workbench will *NOT* work.  This is
>> because the Shell is a window on the Workbench screen that is not part of
>> Workbench itself.  Intuition cannot force "visitor" windows to close, so it
>> cannot close Workbench.
>
>If this is true then I should still see the Workbench screen etc. if I
>push Amiga-A, correct??   When I do this I see nothing, just a blank blue
>screen which indicates to me that it has worked.

  As somebody mentioned, AMOS doesn't always load the copper list correctly
when switching to Workbench.  Does this happen all the time, though?  If so,
then it sounds like something's wrong.

  An extract from the 1.3 Includes & Autodocs RKM:

+++     This routine attempts to close the Workbench.  The actions taken are:
+++   -   Test whether or not any applications have opened Windows on the
+++       Workbench, and return FALSE if so.

>    The manual does say it should be Screen Swap then Wait Vbl.  If
>the Screen Swap is meant to occur just after the next Vblank then why do
>you need a Wait Vbl at all??  If you leave out the Wait Vbl's then 9 times
>out of 10 the flickering is worse (As I found in the game I am now writing).

  See above.  You'll be drawing into the currently displayed screen.

>    I haven't actually examined the code lately but I may have used
>Screen Copy instead of Scroll.  This could be the problem as Screen Copy
>is slower (I think thats right I can't remember correctly,  but I do know
>that after my tests on this I do now use scroll).

  They should be about the same.  Both involve copying blocks of memory.
Scroll may be a bit faster if it calculates the stuff it needs to (blitter
registers, etc.) when you do a Def Scroll, but that kind of difference
shouldn't be noticeable.

>    With reguards to the timing of the flicker I don't know that this
>is totally valid.  It does show that when it occurs it is fairly constant
>but in my experience the flicker does not always happen.  I have had the
>program run before with no flickers,  which just doesn't seem correct.

  See if it has anything to do with the status of the Workbench.  I had a
program that slowed down for apparently no reason if my Workbench was
interlaced.

>>    The only reason this would be needed is just incase the drawing
>>etc. takes less than 1/2 a second and that once the screenswap has been
>>called the program continues with the next update.  But in theory this
>>should just create a que of future screen swaps at future Vblanks.
>
>PAL is a 50Hz update, I think. Screens would be swapped every 1/50th of a sec.

  Yes.  Also, doing a queue of Screen Swaps, if your update is faster than
1/50th of a second, would cause the user's input to be wrong, as the user
would be seeing old display data.  (Or something like that...)

>And I think that it if you did two Screen Swaps, the same physical screen would
>be redrawn next time.

  Yup.

--------
  (phew...)

  Has anyone else noticed that the volume on this list is incredibly high all
of a sudden?  :-)

  --Andy Church